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Abstract - The Mars Science Laboratory (MSL) Project is an aggressive mission launching in 2009 to 
investigate the Martian environment and requires new capabilities that are currently are not available. 
The MSL Technology Program is developing a wide-range of technologies needed for this Mission 
and potentially other space missions. The MSL Technology Program reports to both the MSL Project 
and the Mars Technology Program (MTP). The dual reporting process creates a challenging 
management situation, but ensures the new technology meets both the specific MSL requirements and 
the broader Mars Program requirements. 

MTP is a NASA-wide technology development program managed by JPL and is divided into a 
Focused Program and a Base Program. The MSL Technology Program is under the focused program 
and is tightly coupled to MSL’s mission milestones and deliverables. The technology budget is 
separate from the flight Project budget, but the technology’s requirements and the development 
process are tightly coordinated with the Project. 

The MSL Technology Program combines the proven management techniques of flight projects with 
the commercial technology management strategies of industry and academia, to create a technology 
management program that meets the short-term requirements of MSL and the long-term requirements 
of MTP. This paper examines the initiation of 2002 MSL Technology program. Some of the areas 
discussed in this paper include technology definition, task selection, technology management, and 
technology assessment. This paper also provides an update of the 2003 MSL technology program and 
examines some of the drivers that changed the program from its initiation. 
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1. Introduction 


The Mars Science Laboratory (MSL) Project is an aggressive mission launching in 2009 to investigate 
the Martian environment. The MSL Project initiated its Technology Program in 2002 while in its pre- 
formulation phase. This paper examines MSL’s plans, developed in 2002, to define and initiate its 
technology program. 

The Mars Technology Program (MTP) is comprised of a Focused Technology Program and a Base 
Technology Program [3]. MSL’s Technology Program is under the MTP Focused Technology 
Program and is roughly an $80 million effort to develop the technology needed to meet the unique 
requirements of the MSL Mission. 

The MSL mission introduces a number of significant technological innovations. The most important of 
these are: 1) the ability to make a safe landing at almost any locality on Mars (high altitude and 
latitude) and 2) the ability to operate an analytical science laboratory on the surface of Mars. These 
technology innovations carry forward into future missions in the second decade of this century. 

The Base Technology Program develops enhancing technologies for missions proposed for 2009 and 
beyond. The Base Program stresses breakthrough technology elements that are not in the critical path 
of missions. It addresses technology needs that are less mature and higher risk (and higher payoff) 
than those constituting the Focused Program. 


2. MSL Technology Overview 

MSL is the first mission with an onboard science laboratory that performs in-situ analytical 
experiments. In addition to being a full science mission, MSL will also provide technology feed 
forward to future missions that require the ability to land large payloads on Mars such as a Mars 
Sample Return mission. The MSL mission, with its goal of a 500 sols (Martian days) mission life, is 
defined to be a long-life mission. 

From a technology point of view, there are two main technology areas that are required to be 
developed for the mission. One is the Entry, Descent, and Landing (EDL) capability and the second is 
Surface System technologies. Surface system technology includes rover technology, long-life 
systems, and onboard sample preparation and distribution experiment. The following paragraphs 
describe these technology developments. 


2.1 Entry, Descent and Landing (EDL) 

One of the main goals of the MSL technology program is to develop the capability to land safely near 
any chosen site (including higher elevations) in order to provide a near global access to Mars. To 
achieve this ability to land safely at any locality on Mars, the entire process of entry, descent and 
landing was reviewed and innovations are planned to provide the needed capabilities. Figure 2-1 
shows the EDL technology goals. 
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Past Mars Mission utilized radio-based approach navigation, no control of the lift vector during entry, 
a single stage parachute, and hazard tolerance only to the extent that either airbags or landing struts are 
utilized. There was no hazard detection/avoidance capability. Variants of this approach were used on 
Viking and Pathfinder and will be used on the Mars 2003 mission (MER). The errors in approach 
navigation propagate through the trajectory, resulting in a landing error ellipse ranging from 100 km 
cross range to 300 km along the downrange vector. The payload mass that can be delivered using 
existing or anticipated launch vehicles with this system is limited to ~ 70 kg. 



'Hazard 
Detection and 
Avoidance 


Modified Viking 
Engine for Descent 

'Robust Landing 


Figure 2-1 - MSL’s EDL Technologies Goals. 


Precision landing reduces the risk of encountering hazardous areas such as large craters and steep 
canyons at any given region of Mars where it is desired to land. The goal of MTP is to develop new 
technology to reduce the landing error ellipse to smaller than 3x10 km. In addition the payload mass 
will be raised to - 300 kg. To achieve this goal, each step of the EDL process is upgraded with new 
technology. Each step is developed with advanced technology, with systems integration used to assure 
that all the pieces fit together. To achieve this goal, three complementary technologies are being 
developed: 1) Precision landing, 2) Hazard avoidance, and 3) Robust landing. 

Precision Landing - A lifting entry vehicle is being developed with L/D - 0.25 (lift/drag) that is 
capable of actively guiding itself from entry to parachute deployment despite uncertainties in the entry 
conditions, atmospheric density profile, winds and aerodynamic performance. The two-stage 
parachute system includes a supersonic chute and a subsonic chute. Improved descent propulsion will 
be achieved by recapturing Viking technology with new improved components. 


Hazard Detection and Avoidance - Hazard avoidance provides an “eyes wide open” capability at 
landing. The overall process is illustrated in Figure 2-1. This makes it possible to make adjustments to 
the landing location to avoid large craters, large rocks and steep local slopes. MSL is developing an 
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integrated terminal guidance, navigation, and control system that predicts the descent flight path after 
the subsonic parachute is deployed, detects hazards such as rocks and slopes using active sensors, and 
after jettisoning the parachute, steers the lander to a safe landing area. A RADAR sensing system for 
0-7 km altitudes is in development to generate initial terrain maps and create initial estimates of the 
landing area at ~ 7 km altitude. This system provides more time for the lander to be laterally 
maneuvered to avoid undesirable landing sites. 

Robust Landing - Once landing is committed to, this technology makes it possible to tolerate the 
unexpected or provide resilience to failures in either precision landing or hazard avoidance systems. 
The baseline plan is to get away from the landing pallet system and all its mass, egress, and design 
problems and develop a skycrane system that is less complex and provides better technology feed 
forward capability. 


2.2 Surface System Technologies 

These technologies include all the technologies that enable a rover to travel long distances, place 
instruments autonomously, and analyze samples in its onboard laboratory. The rover and its 
instrumentation must last at least 500 sols (Martian days). 



Figure 2-2 - MSL’s Surface System Technologies. 


Improved rover autonomy is developed to enable safe navigation as well as autonomous science 
operations for Mars surface missions. The strategy is to integrate technologies from MTP’s Base 
Program that are competitively selected and integrate them to demonstrate the capabilities that are 
required for MSL. The Base Program is developing technology for the on-board capability to 
potentially negotiate relatively long distances without supervision from the Earth during traverses 
from one exploration site to another. The time delay inherent to Earth-Mars communications makes it 
impractical to carry out long traverses with Earth supervision. New instrument concepts will be 
integrated with rover platforms. These technologies will be fully tested and validated with full-scale 
remote terrestrial field trials in simulated Mars terrain, including simulated science operations. 
Comprehensive control architecture is being developed for autonomous rovers that capture the state of 
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the art in robotics and autonomy software. This system is distinguished by its layered structure using 
object-oriented hierarchies. 

Long Life - A study was conducted to determine which of the rover components are likely to fail 
during the 500 sol mission and it revealed that there are major weaknesses in the area of mechanical 
systems, particularly motors and bearings. Another major area was the electronics which would be 
exposed to the extreme Martian temperature fluctuation. MSL has a Thermal Cycle Resistant 
Electronics (TCRE) task to test potential hardware under realistic conditions. 

Sample Processing and Distribution Experiment (SPADE) - One of the main differences between 
MSL and past Mars missions is MSL’s capability to analyze Martian samples onboard its analytical 
laboratory. The laboratory consists of science instruments, sample acquisition, processing, and 
distribution system. 

The objective of the Sample Processing and Distribution Experiment (SPADE) system is to crush 
rocks (0.1-1 mm) and distribute them to various onboard science instruments. Cross contamination for 
this type of a system is a major concern. A technology requirement has been established to insure that 
no more than 5% contamination results from one sample to the next. This number can be decreased by 
processing the second sample more than once, thus reducing the contamination to levels below 5%. 

The previous paragraphs provided an overview of the technologies needed for the MSL Mission. The 
following sections describe how MSL and MTP defined, selected, and managed the specific 
technologies need by MSL. 


3. 2002 Technology Program Implementation 

The purpose of the MSL technology program is to retire technical risks while the project is in 
formulation and before it enters implementation. If a technology risk cannot be retired before 
implementation, the project still has time to select another technology and modify their mission 
concept. The technology program matures the most effective technologies while balancing each 
technology’s performance, cost, risk, and schedule. During the technology program, MSL matures the 
required technologies from their present Technology Readiness Level (TRL) that is typically between 
TRL 2 and 3 to a TRL 6. 

TRLs are a systematic metric/measurement system that supports assessments of the maturity of a 
space technology and provides a method of comparing maturity between different types of technology. 
The TRL scale is from 1 to 9, where 1 represents a technology principle and 9 represents a technology 
flown successfully in space. Projects that are not technology demonstration missions typically don’t 
accept the risk of including a technology with a TRL of less than 6 in their design concept. TRL 6 
corresponds to a technology functioning in a subsystem (model or prototype) in a relevant 
environment (ground or space). 

NASA’s guidelines for Project Management, NPG 7120.5B, states: 
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The purpose of the formulation subprocess is to define a project concept and plan for 
implementation to meet mission objectives... The formulation subprocess ... assesses the 
technology requirements and develops the plans for achieving the technology options ... [1] 

The following sections describe how MSL defined its project concept, assessed its technology 
requirements, and developed its technology implementation plan. 

MSL’s technology implementation process, show in Figure 3-1, include three major stages: 
technology definition, technology task selection, and technology management. The following sections 
describe each of these efforts and relate them back to Figure 3-1. Figure 3-1, MSL Technology 
Implementation Plan, also lists the paragraph numbers of the following sections to show how the flow 
of the paper corresponds to the flow of die technology implementation process. 



Figure 3-1 - MSL Technology Implementation Process 
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3.1 Technology Definition 

The first stage of MSL’s technology implementation process is Technology Definition. In this stage, 
as described below, the different organizations work together and produce science requirements, a 
mission concept, a mission risk list, and a list of candidate technologies that reduce the mission risks. 


3.1.1 Development Organization 

Central to implementing a successful technology program is an effective organization structure. The 
following section describes the 2002 MSL organization (shown in Figure 3-2) that defined and 
initiated the MSL technology program. The positions in this organization chart will be referred to as 
the implementation process is described. The roles and responsibilities of each position in the 
organization are described below. 



Figure 3-2 - MSL 2002 Technology Organization Chart 
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At the top and center of this chart are the Science Definition Team (SDT) and the Mars Program 
System Engineering Team (MPSET). The SDT defines and prioritizes the science goals, objectives, 
investigations, and measurements of MSL. The SDT ensures that the MSL science requirements and 
mission concept are consistent with Mars Program science themes. The MPSET ensures that the Mars 
Program is optimized as a whole and not on a basis of project by project. MPSET also works with the 
Mars Technology Program and constituent projects to maximize the program’s technology readiness. 

If a technology is needed for multiple missions, MPSET ensures that the requirements of both 
missions are included in the initial development effort. For example, a previous Mars mission (MRO) 
developed an optical navigation (OpNav) camera and included the requirements of both the MRO and 
MSL mission in the development process. The minimal cost to MRO is justified by the significant 
benefit to MSL and the Mars Program in general. 

An interesting feature of the MSL Technology Program is the dual reporting structure in the 
organization chart. The MSL Focused Technology Manager reports to both the Mars Technology 
Program (MTP) Program Manager and the MSL Project Manager. The MSL Project Manager ensures 
technology meets the MSL focused requirements and the MTP Program manager ensures technology 
meets the long-range requirements of the Mars Program. This inherent conflict actually benefits the 
project and the program by providing a check-and-balance to many budget decisions. 

Five Element Managers report to MSL Technology Manager. The Element Managers are responsible 
for major systems in the project and ensure that the technologies underdeveloped are compatible with 
the latest mission concept. 


3.1.2 Science Requirements and Mission Concept 

The first step in technology implementation (Figure 3-1) is to define the technology to be developed. 
This may sound obvious and simple, but in a large organization with competing views, issues, and 
priorities, agreeing on technology requirements is a challenging task. 

On MSL the process began with the project working with both the MPSET and the SDT to develop the 
mission science requirements (Level 1). Next, the project manager, element managers, and different 
working groups transformed these requirements into a baseline mission concept (where ‘baseline’ 
implies the concept will change as the both the technology and the project definition matures). The 
project uses the baseline mission concept to generate the system-level performance requirements. The 
following sections concentrate on the process of converting the mission concept into an effective 
technology implementation plan. 


3.1.3 Mapping Requirements to Technology 

The technology definition process continues by reviewing the mission concept and the system-level 
performance requirements in informal (peer) reviews, formal reviews, and working group meetings. 
These reviews and meetings defined the major risks with meeting the system-level performance 
requirements and identify candidate technologies to reduce these risks. 
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Mission risks include performance risks, costs risks, and schedule risks. Through MSL’s technology 
definition and selection process, the project initiated technology tasks that reduced risk in all three 
areas. 

MSL then used a process for managing these risks called Defect Detection and Prevention (DDP) [4], 
The DDP process has three steps: 1) determine where we want to be, 2) identify what could get in the 
way, and 3) decide how we will get there. MSL implemented the DDP steps and put their system- 
level performance requirements in a tree structure to ‘determine where we want to be’ and captured as 
trees of potential failure modes ‘what could get in the way’. MSL than scored the impacts of these 
failure modes on the science requirements to prioritize the failure modes. From the list of failure 
modes, MSL created their initial Mission Risk List. 

The third step, ‘decide how we will get there’, is probably the most challenging and requires the most 
iterations with the project, program, and cost modeling organizations. Technology investments were 
assigned to each risk area and the DDP tool captured the estimate of how each risk area was reduced. 

A ‘top down’ approach, based on cost models and project experience, was used to estimate the cost of 
the different technology investments. A ‘bottom up’ cost estimate is done after a task manager is 
assigned and this process is examined in a following section. 

Each technology investment, constrained by the technology budget, addressed an item on the 
prioritized risk list. The risks, and their corresponding technology, include performance risk, schedule 
risk, or cost risk. An example of the three types of risk and their corresponding technology is as 
follows: 1) current engines don’t meet MSL performance requirements so an investment was made in 
new engines, 2) current operations schedule does not meet MSL extended life requirements so 
investments were made to improve operations and science collaboration; and 3) the cost (in dollars and 
mass) to heat external electronics is high so MSL is investing in temperature extreme electronics. 

The process to determine which combination of technologies minimize mission risk and should be 
funded is described in the following sections. 


3.2 Technology Selection 

The second stage of MSL’s technology implementation process was Technology Selection. This stage 
started with a list of candidate technologies and produced detailed implementation plans for each 
technology task. The MSL technology selection process took five months for most of its tasks and an 
additional four months to refocus and select the remaining tasks. The Technology Selection process is 
examined in the following paragraphs. 


3.2.1 Assign Task Managers 

After MSL agreed to a candidate list of technologies, the Mars Program, MSL Project, and MSL’s 
Element Managers selected Task Managers to lead the development effort of each task. These Task 
Managers are typically technologists with mixed levels of flight project experience. Since MSL is a 
focused technology effort, these tasks managers are expected to become integral members of the 
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project team. Element Managers work with each of the Task Managers to ensure projects 
requirements are meet. The tightly coupled technology/project environment required the technologist 
to be less autonomous and more driven by project cost, schedule, and performance constrains. This 
initially was challenging for the technologists accustomed to working independently, but the common 
goal of a successful flight project helped unify the diverse team members. 


3.2.2 Prepare Task Proposals 

Using the baseline mission concept and the system-level performance requirements , each task manager 
worked with their element manager to develop a presentation that proposed how their task would meet 
the mission requirements. These proposals were presented to the MTP Program Manager and the 
MSL Project Team. The presentations described how the task would improve the current state-of-the- 
art, for what cost, and in what schedule. The following is a detailed list of what each presentation 
included. 

Overview ( Quad Chart) - A one slide summary of the proposed task including a representative 
picture, objectives summary, milestones list, organizations involved, collaborators, outside companies, 
and a subtask multi-year schedule including funding levels. 

Objectives and approach - These slides described the overall task objectives, quantified the current 
state of the art, and quantified the new performance goals. Explained the implementation approach to 
meet these goals and include a bottom-up cost summary. The cost summary included the costs for 
each fiscal year, the rational for the costs, and bases of estimate. In addition, the task’s milestones (or 
accomplishments) were listed for each fiscal year. Also, each institution involved in the task and their 
role was listed. 

Backup data - Included a list of questions to help the reviews assess the impact, risks, and 
procurements associated the task. These questions included: 1) What is the functional relationship 
between the technology task and the following mission goals: a) land safely, b) land precisely, c) go to 
a specific location, and d) maximize science? 2) What are the assumptions, dependcies, and risks 
associated with the task? 3) If there are outside procurements, a) what size, b) when is it executed, c) 
is it competitive or non-competitive, and d) what is the acquisition plan? 

Receivable / Deliverable Lists - List all the items being received by the task and delivered from the 
task to what project element. A significant difference between a focused technology task and a base 
technology task is the tight coupling of the technology task to the flight project. A flight project is 
driven by its launch date and other key milestones. A technology task must synchronized its 
deliverables and schedule to the flight schedule. Each technology task must closely track what items it 
expects from a flight system or another technology task (i.e. requirements document, concepts 
document, hardware, software, models, etc). In addition, each technology task must closely track what 
items it will deliver to a flight system or another technology task. A problem in one task could ripple 
through multiple tasks and flight systems, so the project must track the dependencies. After a task is 
selected, the project created an integrated schedule showing all the receivable and deliverables 
(Rec/Dels) between the technology tasks and flight systems. This schedule was updated and tracked 
monthly to quickly identify potential problems. 
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3.2.3 Technology Tasks Review 


Approximately thirty technology tasks presented to the MSL Project and the MTP Program in a three 
step process: project reviews, functional organization review, and program review. The project 
reviews included three different reviews over a period of two weeks. The first review was an informal 
walk-through of the tasks to discuss technology requirements and identify major issues. The second 
review was two weeks later and it was a dry-run to prepare for the third and final presentations to 
project management. At each review, the technology implementation concept was tuned to the 
project’s requirements and mission concept. 

The second step in the task review process was the JPL functional organization review. This meeting 
gave the functional managers a chance to review what commitments the task managers were making 
of their organizations. It also provided a forum for the project and the functional organizations to 
discuss the latest technology requirements and mission concept. 

The second step in the task review process was the MTP Year End Review. This four day review, 
conducted by the Mars Technology Program, included reviews internal and external to JPL and the 
Mars Program. They provided and independent assessment of the MSL technologies 
with an eye on the big 


The task review process resulted in three categories of tasks: selected, rejected, and tasks on hold to 
get refocused. Most tasks were selected, but the review process modified most implementation plans 
by changing their budget, development schedules, and development process. Tasks were rejected 
because their modest improvement in the current state-of-the-art did not justified by their requested 
budget. For example, one task proposed reducing the size and mass of a flight system. However, the 
cost and risk of the task did not warrant their small improvement. 

Several tasks were worthy of selection, but their scope or development plans lacked the necessary 
details. These tasks were asked to refocuses their efforts, discuss implementation options with internal 
and external organizations, conduct trade studies, and plan for a delta-review of their task before being 
funded. Most of these tasks received a low level of funding while they developed their concepts, 
complete trade studies, and created new implementation plans. Each of the tasks placed on hold were 
eventually funded, some with a dramatically different scope and implementation plans. 


3.2.4 Technology Development Agreements (TDA) 

Once a technology task was selected, task managers and their element managers developed 
Technology Development Agreements (TDA). A TDA is a roadmap of the process to mature a 
technology from its current TRL to TRL 6. They also contain specific test protocols for each TRL 
transition as well as the associated costs, schedules, and facilities to achieve each TRL transition. 
These Technology Development Agreements (TDA) and their related test protocols represent a 
process that is performance-oriented and paced by the TRL transitions. To maximize the likelihood of 
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meeting the overall schedule and budget, each technology task was assigned reserve funds to cover 
unforeseen problems. 

A TDA is a web-based technology management tool that captures the technical and programmatic 
information related to a technology task. NASA Headquarters requires JPL and other NASA Centers 
to complete an annual technology inventory. TDAs capture the information required by this 
technology inventory. 

The data captured by TDAa are summarized bellow. 

Introduction - Describes the technology, assesses the state-of-the-art, and defines the current 
Technology Readiness Level (TRL). 

Objectives - Describes the task’s technical objectives and goals. In addition, this field defines the 
specific mission requirements this task will enable. 

Technical Approach - Describes the methodology and approaches to conduct the proposed 
development. Define the products and/or expected results. Provides information on technology 
development approaches such as analysis, experiment, field testing, and, if applicable, flight 
validation. 

Significance - Explains in what way this task will contribute to a NASA Mission. Examples are 
mission enabling, mission enhancing, increasing safety margin, reducing mass, lowering mission cost, 
etc. Mention possible applications to other missions. Describes the technology’s current performance 
level and what level of performance the new technology will achieve. 

Milestones and Deliverables - Identifies the dates when major milestones will be achieved. At least 
three milestones is required in each fiscal year of the task. The list includes events, dates, and 
descriptions. 

Funding Distribution - Lists the type of budget elements (people, parts, etc), who is being funded, 
which fiscal year, the yearly totals, and the total to complete. This field is completed after the task 
manager completes the budget estimate tool (Friendly Front End, FFE). The FFE tool is described 
later in this section. 

Documented Partnerships/Cooperative Agreements - Describes any formal partnerships, cooperative 
agreements, or other agreements that involve this task. However, proprietary or partner sensitive 
information are not to be included in this field. 

Comments - This field answers the following questions (as appropriate): 

1. What is the impact if funding is increased by 20% and decreased by 20 %? 

2. What are the priorities of the different sub-tasks? 

3. What is the task’s probably of success and the backup plan if not successful? 

4. How is this technology dependent on other development efforts? 

5. Can the technology scale for different configurations and what is the impact on mass and power? 

6. What are the technology’s interfaces are they standard (if appropriate)? 

7. Describe any out-of-house efforts related to this task and at what level of funding. 
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8. What procurements are planned and what is the acquisition plan? 

Infusion Plan - Defines the plan for applying the technology developed in this task to a practical 
implementation. Final implementation includes either a flight project or a ground application. 

Reporting Plan - Defines the plan for reporting status/progress on this task to management. This 
should include task reviews, non-advocate reviews, project review, written reports and publications. 

Commercialization Plan - Defines the plan for transferring the technology developed in this task to 
commercial use. If appropriate, this field identifies the industry partner teaming on the 
commercialization effort. If the technology has no commercial potential, this field contains a “N/A”. 

Approval - The TDA sequence of approval is: Task Manager, Element Manager (or Level- 1 
Manager), Section Manager, and Project Office. 

Other members of the project team, including members of the science team, review the technologies at 
the initial proposal review and the periodic status reviews. After the TDA is approved, the Project 
implements the technology development task. The TDA is now under Configuration Management 
(CM) control and any future changes require MSL technology Change Control Board (CCB) approval. 
The MSL technology CCB is discussed later in this section. TDAs are reviewed at the end of every 
fiscal year and changes are made to reflect the technology development updates for next fiscal year. 


3.2.5 Technology Budget Worksheet (FFE) 

Each task is given a fixed amount of money to develop its technology. The TDA captures cost 
estimate to complete the task including purchases, travel, subcontracts, and manpower. The data for 
these fields are generated by the Friendly Front End (FFE), a financial spreadsheet tool that collects all 
the budget information for the technology development task. The FFE permits great detail in the cost 
estimates and the rates and factors are already incorporated into the FFE. The FFE is used for 
estimating: Workforce, Procurements & Subcontracts, and Travel/Services. For more information on 
the FFE, view the training guide at http://rms.ipl.nasa.gov . 

Every month, MSL’s Project Resource Analysts (PRA) generates financial reports for each technology 
development task. These reports list the task’s actual spending, compares the actual costs to the 
planned budget, and flags any variances. If a technology development task is under-running or 
overspending, the task manager must explain the discrepancy at the next MMR and assess the impact 
to both the technology task and the MSL Project. 


3.3 Technology Management 

The third stage of MSL’s technology implementation process is Technology Management. This stage 
started the technology tasks are approved and continues until the tasks are completed. A task is 
completed when it reaches a Technology Readiness Level (TRL) of 6, which typically requires three 
years. The Technology Management process is examined in the following paragraphs. 
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Hawthorn Effect - Improved process data that results from process operators who know their process 
performance is being measured and exercise more care in the execution of the process than would 
normally be done. 

Individual behaviors may be altered because they know they are being studied was demonstrated in a 
research project (1927 - 1932) of the Hawthorne Plant of the Western Electric Company in Cicero, 
Illinois. This series of research, first led by Harvard Business School professor Elton Mayo along with 
associates F.J. Roethlisberger and William J. Dickson started out by examining the physical and 
environmental influences of the workplace (e.g. brightness of lights, humidity) and later, moved into 
the psychological aspects (e.g. breaks, group pressure, working hours, managerial leadership). The 
ideas that this team developed about the social dynamics of groups in the work setting had lasting 
influence - the collection of data, labor-management relations, and informal interaction among factory 
employees. 

The major finding of the study was that almost regardless of the experimental manipulation employed, 
the production of the workers seemed to improve. One reasonable conclusion is that the workers were 
pleased to receive attention from the researchers who expressed an interest in them. The study was 
only expected to last one year, but because the researchers were set back each time they tried to relate 
the manipulated physical conditions to the worker’s efficiency, the project extended out to five years. 

Four general conclusions were drawn from the Hawthorne studies: 

• The aptitudes of individuals are imperfect predictors of job performance. Although they 
give some indication of the physical and mental potential of the individual, the amount 
produced is strongly influenced by social factors. 

• Informal organization affects productivity. The Hawthorne researchers discovered a 
group life among the workers. The studies also showed that the relations that supervisors 
develop with workers tend to influence the manner in which the workers carry out directives. 

• Work-group norms affect productivity. The Hawthorne researchers were not the first to 
recognize that work groups tend to arrive at norms of what is "a fair day’s work," however, 
they provided the best systematic description and interpretation of this phenomenon. 

• The workplace is a social system. The Hawthorne researchers came to view the workplace as 
a social system made up of interdependent parts. 

For decades, the Hawthorne studies provided the rationale for human relations within the organization. 
Then two researchers used a new procedure called "time-series analyses." Using the original variables 
and including in the Great Depression and the instance of a managerial discipline in which two 
insubordinate and mediocre workers were replaced by two different productive workers (one who took 
the role of straw boss - see below). They discovered that production was most affected by the 
replacement of the two workers due to their greater productivity and the affect of the disciplinary 
action on the other workers. The occurrence of the Depression also encouraged job productivity, 
perhaps through the increased importance of jobs and the fear of losing them. Rest periods and a group 
incentive plan also had a somewhat positive smaller effect on productivity. These variables accounted 
for almost all the variation in productivity during the experimental period. Social science may have 
been to readily to embrace the original Hawthorne interpretations since it was looking for theories or 
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work motivation that were more humane and democratic. - Franke, R.H. & Kaul, J.D. "The 
Hawthorne experiments: First statistical interpretation." American Sociological Review, 1978, 43, 623- 
643. 


3.3.1 Weekly Element Meetings 

The Element Managers are responsible for organizing and conducting weekly technical reviews of the 
technologies in their element. The appropriate task managers and the appropriate project system 
engineers support these weekly technical reviews. Theses reviews discuss the technical progress of 
the technology tasks, examine the dependencies of the different, and reviews both the impact of 
technology on the project’s concept and the impact of the maturing project concept on the technology. 

During the program, the Element Managers track the progress of both the mission concept and the 
technology development efforts. As the mission concept changes, the technology requirements are 
updated and as the technology effort makes progress, the mission concept is updated. 


3.3.2 Monthly Management Reviews (MMR) 

MMRs are organized and conducted by the MSL Technology Manager. The MMR are supported by 
the line organizations, the Program Office, and collaborating NASA centers. The MMR reviews 
technical progress (planned v. actual), action items, development issues, development budgets, and 
deliverable schedules. 


The MMR is supported by the project and the functional organizations, but every quarter the MMR is 
opened to a broader audience. The Project Manager organizes and conducts the Quarterly Reviews in 
January, April, July, and October of each calendar year, which replace that month’s MMR. The 
Element Managers prepare and present the Quarterly Reviews for their respective technical areas. The 
participants include MSL Project staff, NASA Program Executives, representatives from collaborating 
NASA centers, line management, and technology customers (project and pre-project managers). 


3.3.3 Technology Change Process 

As the MSL technology tasks proceed and as the MSL Project concept matures, changes to the 
technology tasks are inevitable. In addition, the MSL technology program is managed by both the 
MSL Project and the MTP Program, each with a slightly different focus. MSL desires to optimize the 
project and MTP desires to optimize the program. The technology change control process (shown in 
Figure 3-3) was established to involve all impacted parties in the change process and to balance the 
health tension between the project and the program. 

The change process is initiated when a Task Manager (TM) drafts a Technology Change Request 
(TCR) from. The TRC is developed with and approved by both the TM’s line management and 
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Element Manager (EM). The line manager and the EM ensure that the change is consistent with 
project’s desire and the functional organizations ability. 

The TCR is then evaluated by the Technology Manager and the impact on the project’ s budget, 
schedule, and performance is accesses. If the change is significant or the change is controversial, the 
change is added to the project’s lien list and the Technology Manager presents the change to the 
Change Control Board (CCB). If the change is not significant, it is approved and implemented by the 
Technology Manager. Significant changes are those that cost more than $20k or impact a schedule by 
more that one-month and controversial changes are those that potential impacts the project-program 
balance. The project’s lien list are all open technology change requests. 

The CCB meets once a month (if required) and examines any open TCRs in a systematic manner to 
determine its impact on the project’s risk, cost, schedule, and performance profile. The CCB ensures 
that all affected parties are cognizant of the change and have a voice in the decision making process. 
The MSL Project Manager and MTP Program Manager chair the Change Control Board (CCB) and 
have authority to approve any changes which do not affect the projects Level 1 requirements. Advisor 
members of the CCB include the Technology Manager, the Element Managers, and the project Chief 
Engineer. 

The MSL technology program maintains budget reserves to cover changes and other problems with 
the technology program. The lien list and the technology budget reserves are reviewed at the monthly 
Change Control Board (CCB) meetings. The CCB balances the projects and the technology 
program’s risk, cost, schedule, and performance. The CCB can decide to approve or disapprove a 
TCR. The CCB can also decide to keep the TCR open and review it again at the next CCB meeting. 
Projects are reluctant to spend reserves early in the fiscal year, but later in the year when potential 
problems are better understood, a lien may be approved. 

In addition to reviewing changes, if a technology task is not performing due to cost, schedule, 
performance, or risk issues, the CCB can decide if the performance and priority of the task, warrant 
the spending of the technology reserves (budget, mass, power, or schedule) to address these issues. 
Another option is to cancel a technology task, adopt the current state-of-the-art performance, and fund 
a more promising effort on the technology lien list. The lien list and the different funding options 
provide a sense of urgency to the task managers to keep their tasks on track. 
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Figure 3-3 - The MSL Technology Change Control Flow 


3.3.4 Year-End Review (YER) 

The MTP Program Manager organizes an October year-end review and assembles a peer review panel. 
The panel includes appropriate technical and programmatic personnel from JPL, NASA centers, 
NASA Headquarters, and universities. The MTP Program Manager or his designee chairs the peer 
review panel and provide a summary of review results and recommendations to the MSL Project 
Manager. The review feedback will be used to improve the technology program by implementing the 
review panel recommendations as appropriate. 


3.3.5 Technology Readiness Certification Review 
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Traditionally, a major issue with NASA technology programs is there in ability to successfully infuse 
their technology into flight project. To help solve this, the MSL technology program is a focused 
program and includes the MSL Project Team in the selection and implementation of the technologies. 
The infusion plans of each technology are also captured in the task’s TDA. 

In addition, to help accelerate and simplify the technology infusion process, MSL established a 
Technology Readiness Certification Review (TRCR) process. In this process, the Task Manager 
prepares a data package on their technology and presents the package to the project. The package 
includes the criteria the task used to meet their TRL 6 requirements. For each technology, the TRCR 
package includes all the design, fabrication, assembly, and test information the project needs to 
implement the technology. 


4. Technology Assessment Tools 

The previous sections described the first year of the MSL technology program and defined the 
processes for defining, selecting, and managing the focused technology tasks. In addition to the 
processes defined above, the first year of the technology program also implemented a number of 
technology assessment tools. These tools and their pros and cons are described in the following 
sections. A change in technology management occurred between the first and second year of the 
technology program and the tools were no longer implemented. The tools, however, were useful 
during the first year and warrant a discussion. 


4.1 Aggregate Project Plan (Bubble Chart) 

For each technology being developed, the aggregate project plan (or bubble chart) maps the technical 
impact of the technology task against the risk of the task. The chart also includes the budget allocation 
and budget status of each task. This chart allows managers to quickly assess the status of all 
technology tasks. A technology portfolio (represented by the aggregate project plan), like a financial 
portfolio, should be balanced. That is, the risk of developing a technology should be commensurate 
with the technology’s predicted performance or impact. For example, a high-risk technology should 
have a high impact and a low impact technology better have a low development risk. In addition, if a 
technology has a high impact, but a low development risk, maybe it should be moved out of the 
technology effort and into a flight system. 

The aggregate project plan is updated every month with the latest status of the technology tasks. The 
bubble’s x/y-location corresponds to the risk/impact of the technology; the size of the bubble 
corresponds to the task’s budget, the color of the bubble corresponds to the task’s financial status (red 
= +/- >10%, yellow = +/- 5% to 10%, green = on budget); and the color of the bubble’s ring 
corresponds to the status of the task’s risk/decision analysis assessment. Figure 4-2 is an example of 
the MSL’s technology aggregate project plan. 

The following defines the X- and Y-axis of the aggregate project plan: 

- New Core Product - Fills previously unknown, unmet needs. This is the first introduction of a 
revolutionary new technology. Stimulates new usage and system designs. 
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- New Benefits - Fills known but as yet unmet needs. Delivers new concepts and benefits that fulfill 
needs that are otherwise unmet by any technology 

- Improvement - Better meets needs or meets more needs. This impact is significant, discernible 
improvement, amplification, or enhancement relative to existing technology benefits. 

Variant - Meets same needs differently. This is a minor revision, adjustment, and alterations with 
relative parity to existing product performance, claims, & features. 


Figure 4-1 - A 2002 MSL Aggregate Project Plan (Bubble Chart) 
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- No Change - This technology meets the same needs with no change. No perceived activity, but 
involving improved processes that result in cost reductions or meet project/program mandate with 
no change in quality or other benefits. 

- Radical - First use of a Technology that is new to the industry 

- Next Generation - Pushes existing Technologies into a completely different application 

- Incremental - Extends existing Technologies beyond the normal application 

- Base - Exploits current standard Technology without extending the range of applications 
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4.2 Technology Funnel Chart 

Funnel Chart - The technology funnel chart maps the high-level project schedule against the 
schedule status of each the technology tasks. It also captures the budget allocation and schedule 
status of each task. The funnel chart defines the separation between different technology development 
stages. The process provides a clear criteria for a technology to proceed to its next development step. 
It also provides a way to kill technology development efforts that are not performing technically, 
financially, schedule-wise, or in risk reduction. The funnel chart enables program and project 
managers to engage technologists at the right time to correct technical and programmatic issues before 
they impact the project. It also provides a continuous process to verify that the technology fits with 
the project and program strategy and system architecture. The overall shape of the funnel chart 
implies that some technology tasks are eliminated as the project refines its implementation concept 
and some technology tasks cannot meet their requirements. 
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Figure 4-2 - A 2002 MSL Technology Funnel Chart 


The primary gates (represented by horizontal diamonds) on the funnel chart are the yearly non- 
advocate reviews and the quarterly program reviews. These gates give technologists the freedom they 
need between gates to develop their technologies. This phased gate model facilitates a common 
understanding of technology task progress. The gates allow the project to defined, track, and review 
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tasks according to predetermined decision criteria. They also give a project visibility across tasks and 
elements with standard terminology and simplified reporting. The selection criteria for a task to pass 
from one phase of the funnel chart to the next include: are key project needs identified and met; will 
the technology be delivered within budget, schedule, and risk constraints; and does the technology fit 
the project architecture. 

The ovals in the bottom of the funnel chart represent the documents the technology tasks develop to 
describe their tasks. These documents include the TDA and FFE, which reflect the detailed technical 
description of the task and the budget required to meet the technical requirements. The TDA and 
FFE’s are periodically update to reflect the latest status of the task. Significant changes to the TDA 
and FFE require approval by the MSL technology CCB to properly assess the impact of any changes. 

Figure 5-2 is an example of the MSL Project’s technology funnel diagram and the MSL Project will 
develop a similar chart when its technology program is initiated. The funnel chart is updated every 
month with the latest status of the technology tasks. The bubble’s x-location corresponds to where the 
technology is on the TRL/progress scale; the size of the bubble corresponds to the task’s budget, the 
color of the bubble corresponds to the task’s schedule status; and the color of the bubble’s ring 
corresponds to the technology’s TDA status. 


4.3 Decision Analysis Tools 

The MSL Project uses a collection of Decision Analysis (DA) and Risk Assessment (RA) tools to 
manage the decisions and risks associated with MSL’s technology development program. One 
example of these tools is the decision tree. The decision tree captures and analyzes the key decisions 
associated with each technology task and the decisions that may impact other technologies and the 
project. A typical decision tree is in Figure 4-3 and the decision analysis associated with this figure 
will be completed for the critical decisions associated each of the technology development tasks. 

Decision trees and the decision analysis process collects the critical decisions of the technology 
program; defines the performance, cost, and risk of each decision option; and establishes a date when 
the decision has to be made. The decision analysis process will ensure that the MSL Project makes 
intelligent and timely technology decisions. 



Figure 4-3 - The Decision Tree Analysis Tool 


2004 IEEE Aerospace Conference 





In addition to the decision analysis, the MSL Project will complete a risk assessment of the key 
technology deliverables. Figure 4-4 is an example of a deliverable’s risk assessment. The 
performance, cost, risk, and date of each critical deliverable will be defined. If the risk of a 
technology’s deliverable is high, a backup option will be defined. For these critical deliverables, the 
development schedules of the primary and backup options will be compared and if necessary, a 
parallel technology development effort will be initiated. 
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Figure 5-4 - The Deliverable Risk Analysis Tool 


5. Conclusion 

The MSL Technology Program is tightly coupled to the MSL mission and the MSL milestones. It 
involves time-critical deliverables that must be developed in time for infusion into the MSL mission. 
The plan is to reach TRL 6 for each technology by the mission’s PDR in 2006. This program 
transcends the usual gulf between technology and projects by vertically integrating the technology 
work with pre-project development in a project-like environment with critical dates for technology 
infusion. The program addresses developing key technology to enable MSL’s revolutionary science 
mission. 
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